Many telecommunication service users obtain their services for or through a corporation or other institution. Thus, a user may obtain a wireless telephone service, electronic mail service, voice dialing service or the like for his or her use as an employee of a corporation. With this arrangement, the institution, the user or both may want the service provider to provide its services using specific data, hereafter referred to as service data, which includes data stored in the institution's database. For example, a user may subscribe to a voice activated dialing (VAD) service for work. The user or the user's employer might then want the service provider to provide the service using service data that includes the contact information stored in the employer's corporate database.
Service providers face a “firewall challenge,” however, when trying to provide services to end users based upon proprietary institutional databases. Specifically, the service providers must deploy their services using infrastructure housed within their data centers and/or networks, but these data centers and networks are situated outside of the security systems or “firewalls” that many institutions use to protect their propriety networks and infrastructure from unauthorized access. Thus, with the example of a voice activated dialing (VAD) service noted above, the employer's contact information may be stored and maintained in a server such as Microsoft Exchange® server or a Lotus Domino® server situated behind the employer's corporate firewall.
For the end user in this example, the simplest solution would be to have the service provider's VAD system directly access the employer's Microsoft Exchange® or Lotus Domino® server and extract the user's contact information directly, without requiring the user's involvement (other than, perhaps, to provide the user's username and password in order to give the provider initial access to the employer's Microsoft Exchange® or Lotus Domino® server). This approach, however, while easiest for the end user and desirable from the service provider's point-of-view, is not one that that will typically meet with the institution's approval. On one hand, the institution will not want its end users to be storing corporate credentials (used to access the institution's servers) on a system located outside the institution's domain. On the other hand, if a service provider's single system attempts to access data within an institution's server on behalf of multiple end users, the institution may have difficulty distinguishing this legitimate access from a hacker's attack, as they have similar characteristics.
One conventional solution to this “firewall challenge” is to deploy a Virtual Private Network (VPN) that securely bridges the service provider's network and infrastructure to the institution's network and infrastructure. Virtual Private Networks have a disadvantage, however, in that they require the institution's participation and significant resources to deploy and support. This disadvantage can be especially cumbersome for larger companies or institutions that are likely to have relationships with several different service providers and/or multiple networks (e.g., for different geographic regions, business units, subsidiaries, etc.).
Still another disadvantage associated with Virtual Private Networks is that they are based on “tunneling” a secure communication session within an insecure communication session that is transported over the public Internet. While this technique avoids the costs associated with building large private networks, it can lead to performance issues, as the “tunneling” process induces additional latency on top of the latency already inherent in communication over the Internet. Further, because Virtual Private Networks are built on top of the Internet, over which neither the service provider nor the institution can have total control, performance of Virtual Private Networks can vary significantly based on time-of-day, geography, and a number of other external factors.
Another conventional solution to the “firewall challenge” uses synchronization technology. With this technique, the data normally stored and managed in the institution's platforms, like Microsoft Exchange® servers and Lotus Domino® servers, situated behind the institution's firewall, is replicated in one or more platforms maintained by the service provider. More particularly, a device behind the institution's firewall periodically connects to the service provider's system in order to (1) communicate changes made to the user's data through the user's normal interaction with the institution's systems, (2) determine if changes have been made to the user's service data as a result of the end user's interaction with the service provider, and (3), as needed, transfer data between the institution's system and the service provider's system and otherwise synchronize multiple instances of the user's service data. This approach overcomes the “firewall challenge” because the synchronization process can be initiated by a system operating within the institution's domain using an approved data transfer protocol, such as HTTP, its encrypted variant, HTTPS, or any other suitable data transfer protocol.
This approach relies on these periodic connections, or “polling”, because the institution's firewall prevents the service provider's systems from sending “change requests” to the institution's systems exactly when such change events occur. In other words, because the service provider's systems cannot directly communicate changes to the service data when and only when such changes occur, the institution's systems must instead periodically “check in” with the service provider's systems to determine if changes have occurred, even if none have. Failure to regularly make a periodic check could leave important changes un-synchronized, leading to user confusion or worse. For example, a time-critical electronic mail message initiated through the service provider's systems may go undelivered to one or more recipients for an unacceptable period of time, or a meeting initiated through the service provider's systems may not be reflected in the institution's systems in a timely fashion leading to a “double-booking” or other conflict in the user's schedule.
The conventional synchronization solution does have some problems, however. Because the synchronization process is initiated by a device or system operating behind the institution's firewall and within the institution's domain, it is necessary for such solutions to employ a “polling” approach where the institution's system periodically polls the service provider's system, as noted above. The selection of the polling interval or “synchronization interval” offers significant tradeoffs. This is because each concurrent connection has both a fixed and recurring cost component and the shorter the synchronization interval the greater the peak number of concurrent connections will be over a given period of time.
The selection of how much and the type of data to be synchronized during each synchronization process also presents significant tradeoffs. Like the synchronization operation, data storage also has fixed and recurring costs, so it is not desirable to store any more data than is needed. Also, the amount of synchronized data is related to the synchronization interval because it takes a finite amount of time to synchronize one or more data sets. Thus the larger the size of each synchronized data set and/or the greater the number of such sets, the longer the required synchronization interval. Otherwise, the number of concurrent synchronization communication sessions required to service every end user would approach the number of overall end users, which would be cost-prohibitive.
Still further, the synchronization interval and the amount of synchronized data both impact the end user's satisfaction. The shorter the synchronization interval, the more closely the synchronization process emulates the responsiveness of a direct access model where the service provider is able to access data in real-time directly from the institution's applications and systems. Similarly, the greater the quantity of data synchronized the synchronization process, the more closely the synchronization process emulates the responsiveness of the service provider accessing all available data by interfacing directly with institution's applications and systems.
The standard solution to these synchronization tradeoffs is to take one of the following approaches: (1) fixed synchronization interval, fixed synchronization data quantity, (2) fixed synchronization interval, user-defined synchronization data quantity, (3) user-defined synchronization interval, fixed synchronization data quantity, or (4) user-defined synchronization interval, user-defined synchronization data quantity. Each of these approaches has drawbacks, however. For example, the fixed synchronization interval, fixed synchronization data quantity approach offers predictable costs and is simple in that no end-user decision-making or configuration is required, but this approach uses an arbitrary synchronization interval and an arbitrary synchronization data quantity that may not meet the needs of all end users.
With the fixed synchronization interval, user-defined synchronization data quantity arrangement, the storage costs are not predictable, and the end-user must be involved in deciding upon and configuring the synchronization data quantity. Moreover, users will tend to “maximize” the synchronized data quantities, thereby driving up storage costs. With the user-defined synchronization interval, fixed synchronization data quantity approach, the connection costs are not predictable, and the end-user must be involved in deciding upon and configuring the synchronization interval. Further, users will tend to “minimize” their synchronization intervals, thereby driving up concurrent connection costs. Lastly, with the user-defined synchronization interval, user-defined synchronization data quantity arrangement, both the connection costs and the storage costs are unpredictable and the end-user must be involved in a significant amount of decision-making and configuration to determine both the synchronization interval and the synchronization data quantities. Moreover, users will tend to minimize the synchronization interval and maximize the synchronized data quantities, driving up both connection costs and the storage costs.